home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / mirc-hidden-files.txt < prev    next >
Encoding:
Internet Message Format  |  1999-03-24  |  3.6 KB
  1. Date: Sat, 2 Jan 1999 06:15:04 -0500
  2. From: Locke Nash Cole <loki@LNETI.COM>
  3. To: BUGTRAQ@netspace.org
  4. Subject: Re: Win32 ICQ 98a flaw
  5.  
  6.  
  7. You can also do this in the popular mIRC IRC Client, althou it has no "Open"
  8. option so there is a less chance of the person running it, however in
  9. explorer
  10.  
  11. "mypic..bmp
  12. .exe"
  13. Kinda looks like a bmp the .exe is hard to see on some view modes, and if
  14. you opened the .exe file up in borland's resource editor (or any similar
  15. editor) and changed the exe files icon to that of mspaint.exe a person
  16. (sometimes even an advanced user) will double click anyway without seeing
  17. the far off .exe portion of the filename..
  18.  
  19. Also if they look in their status window they may discover the .exe, althou
  20. if you use a special dos program to write files to filenames that aren't
  21. normally allowed (with mIRC's CTRL-K color code) you could make the .exe
  22. part invisible in the status window...
  23. using CTRL+K0 for white text, and most people use the default white text
  24. background on the status window.
  25.  
  26.  
  27. I'm sure Eudora/Outlook Express could easily fool a user also into doing the
  28. same thing..
  29.  
  30. ----- Original Message -----
  31. >From: Justin Clift <vapour@DIGITALDISTRIBUTION.COM>
  32. To: <BUGTRAQ@NETSPACE.ORG>
  33. Sent: Thursday, December 31, 1998 10:20 PM
  34. Subject: Win32 ICQ 98a flaw
  35.  
  36.  
  37. >Hello everyone,
  38. >
  39. >A while ago I found a flaw in ICQ which I believe to be fairly serious and
  40. >asked whom to notify.  Thanks for everyone's assistance in this.  :-)
  41. >
  42. >I notified Mirabilis and they have totally failed to respond (I've waited
  43. >about 2 weeks), so I'll now submit it here.
  44. >
  45. >It's a very simple flaw.  At present I've only tested on the Win32 ICQ 98a
  46. >1.30 version, and have not tested on ICQ99 nor on other platforms.
  47. >
  48. >Here is how it works : When a person is sending a file to another user on
  49. >ICQ, the person receiving the file has a window pop up which shows the
  50. >filename, a description entered by the sender, and options of where to save
  51. >or not save etc.
  52. >
  53. >I've found there isn't a check on the length of the filename being sent.
  54. >The pane in the pop-up window will display as much of the filename as it
  55. >can, and if the filename is longer that the pane, the ending remainder
  56. won't
  57. >be displayed.
  58. >
  59. >Therefore a simple attack is possible, sending a file named (for example) :
  60. >
  61. >"leah2.jpg
  62. >.exe"
  63. >
  64. >will display leah2.jpg to the receiving user whom will only see "leah2.jpg"
  65. >in the pop-up window and assume it is a harmless picture file for example,
  66. >not executable code.
  67. >
  68. >This is very bad considering ICQ has the option of 'OPEN'ing the file once
  69. >the transfer is completed.  Many people do this to have the picture
  70. >displayed to them (by the program associated with the extension).  In the
  71. >case of this exploit, the executable code will be run instead of the
  72. program
  73. >the victim is expecting.  A craftily coded program would be able to do both
  74. >so as to avoid suspicion on the part of the victim.
  75. >
  76. >One thing I have noted in testing is that on one person's system running
  77. >Win95 this did not work.  His computer renamed the file to .zip on
  78. receiving
  79. >which stopped the file executing.  I don't know why and as far as I have
  80. >been able to find out (I haven't had physical access to his PC) this is due
  81. >to his personal configuration and is not the norm.
  82. >
  83. >One additional thing should considered also, and I don't yet have the time
  84. >and ability to do so; is a buffer overflow exploit present here or in other
  85. >versions which allows remote automatic code execution?  This depends on the
  86. >program and the protocol, of course.  It could be *very* bad.
  87. >
  88. >Regards and best wishes,
  89. >
  90. >+ Justin Clift
  91. >Digital Distribution
  92. >www.digitaldistribution.com
  93.  
  94.